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Mfthqd and apparatus for Sharing D ata Files among Runtime 

FNVIRONMFNT applets in an INT FGRATED CIRCUIT CARD 

5 TECHNICAL FIELD 

This invention generally relates to integrated circuit cards and, more 
specifically, to a method and apparatus for sharing data files among runtime 
envirorunent applets in an integrated circuit card (ICC). 

10 BACKGROUND OF THE INVENTION 

Today there is increasing use of integrated circuit cards, colloquially referred 
to as "smart cards", in place of, or in addition to, conventional magnetic stripe cards 
("mag cards"). A smart card is a thin card embedded with a memory device 
(volatile and/or non-volatile) and associated programmable or non-programmable 
15 logic. Unlike the mag card that merely stores "static" information (e.g., a credit 
card account number), a smart card can add, delete and otherwise manipulate 
information stored on the card. Accordingly, smart cards are capable of storing and 
executing applications to carry out one or more functions within a smart card. 

A smart card is often referred to as a "closed" system because, for security 
20 purposes, a smart card is purposefully designed to not expose its memory, 
intermediate system states or data and address bus information to external devices. 
To do so would render it susceptible to unauthorized access (hacking) and fraud. 
While its closed namre is useful for secure applications such as banking 
transactions, it makes it difficult to utilize prior art smart cards for development 
25 purposes. It is to be appreciated that application development often requires access 
to memory or bus values, or system state information during intermediate 
processing steps, access that has been specifically designed out of the smart card. 
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Another encumbrance to the smart card application desi^er is the limited 
resources of the smart card. That is, due to the physical and processing constraints 
placed on the smart card, prior art smart cards do not enjoy any dedicated debug 
facilities. Aside from the limited processing and memory attributes of a smart card, 
5 a smart card typically has but a single, bi-directional input/output (I/O) port. The 
communication bandwidth of this single I/O port is typically consumed to support 
execution of the smart card application itself, leaving little to no communication 
bandwidth to support debug feaUires. Thus, application development using a smart 
card itself is vimially impossible. Consequently the development of applications 
10 for a smart card currently requires the use of an in-circuit emulator (ICE) and an 
associated, often proprietary software development application. 

As a result of tlie limited processing and memor>- capability of the smart 
card, and the cost of development, each smart card is typically developed to support 
a few functions. The smart card functionality is typically embodied as a couple of 
15 stand-alone runtime environment applets, stored within a non-volatile memory of 
the smart card, and selectively invoked by a host system. To better illustrate this 
architecture, a block diagram of a typical prior art smart card system architecture is 
presented with reference to Fig. 1. 

As shown, from a hardware perspective, smart card 100 is comprised of an 
20 input/output (I/O) interface 102, control logic 104, non-volatile memory 106 and 
volatile memory 108, coupled as shown. Control logic 104 supports an operating 
system with native functions 110 and a runtime environment (RTE) 112, which 
executes runtime environment applets 114A and 114B accessed from non-volatile 
memory 106. The operating system 110 and RTE 112 are typically invoked when 
25 the smart card is introduced to a host system, e.g., a card reader, which provides 
power to smart card 100. 
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Because of the limited memory and processing capability of the smart card, 
the rumime envirorunent 112 is typically optimized for the functions it performs, 
i.e., to implement the functionality embedded within applets 114. Moreover, 
storage of the applets themselves are optimized, i.e., the bytecode and data for the 
5 applets are compiled and stored as a single executable entity within one or more 
segments of non-volatile memory, as shown. 

h should be appreciated that while the prior art nintime environment and 
applcis were optimized to preserve the processing and memory capabilities of the 
smart card, they do not provide a flexible environment for, say, smart card applet 
10 development. One of the drawbacks of the self-contained applets typical of the 
prior art is that in order to change the functionality of an applet, the data must be 
replaced as well. That is, the code and data of the applet are inextricably tied 
together. 

In addition to limiting the flexibility of the applets, compiling the code and 
15 data into a common file may, in certain circumstances, waste memory resources. 
That is, if two applets required the same data, the prior art dictates that two applet 
files, each with the same data, be stored in the non-volatile memory of the smart 
card. By eliminating this needless duplication, memory resources may be freed to 
extend the functional capability of the smart card. 
20 Thus, a method and apparatus for sharing data files among nintime 

environment applets is required, unencumbered by the limitations commonly 
associated with the prior art. One such solution is presented below. 



SUMMARY CiV THE INVENTION 
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This invention concerns an integrated circuit card (ICC), such as a smart 
card and, more particularly, to a method and apparatus for sharing data files among 
runtime environment applets in an integrated circuit card. 

In accordance with a first aspect of the invention, an integrated circuit card is 
5 presented comprising a storage device having stored thereon one or more code files 
and one or more data files, and control logic. When the ICC is inserted into a card 
reader, the control logic implements an ICC runtime environment that executes an 
applet in response to a command identifying a code file and a data file received 
from a host system. It is to be appreciated that an ICC incorporating the teachings 
10 of the present invention stores and executes discrete code and data files, enabling 
runtime environment applets to share data files between discrete code files, 
acwuiding to one aspect of the invention. 

The runtime environment applets, with discrete code and data files are 
developed using an innovative application development agent that includes a 
15 compiler and a file system builder. In addition to the typical function of translating 
source code into executable bytecodes, the compiler incorporating the teachings of 
the present invention distinguishes the executable bytecode from data, storing the 
executable bytecodes in a code file and the data in a data file. 

The file system builder receives a description of a file system to be 
20 implemented on the ICC and generates a binary image of the file system. 
According to one embodiment of the invention, the received description is an 
ordered series of script commands that describe and build the file system. The 
binary image of the file system is then loaded (or masked) in the non-volatile 
memory of the ICC. 

25 In this regard, the present invention also consists of an ICC file system, 

responsive to an innovative command set which enables a user (or host system 
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program) to add, delete, modify and execute discrete code and data files stored in 
non-volatile memory of the ICC. It will be appreciated that the innovative ICC file 
system enables a user (or host system) to modify the fimctionality of an ICC (i.e., 
add, delete or modify code files) without disrupting the data files. Similarly, the 

5 ICC file system facilitates modification of ICC data stores without modification to 
an ICC functionality. 

Thus, it is to be appreciated that an ICC application development system 
incorporating the innovative compiler and file system builder represents a 
significant advancement in smart card application development and deployment. 

10 By separating an applet into distinct code files and data files, the present invention 
facilitates a much more flexible runtime environment, while reducing the amount of 
memory required to store other.vi3s redundant information. 

RRTFF DESCRIPTION OF THE DRAWINGS 
15 Fig. 1 is a block diagram of a system architecture for a prior art integrated 

circuit card; 

Fig. 2 is a block diagram of an example data network including an integrated 
circuit card incorporating the teachings of the present invention; 

Fig. 3 is a block diagram of an example computer system including an 
20 innovative integrated circuit card application development agent, according to one 
aspect of the present invention; 

Fig. 4 is a block diagram of an example development agent, in accordance 
with the teachings of the present invention; 

Fig. 5 is a block diagram of an example integrated circuit card including a 
25 file system and discrete code files and data files, according to the teachings of the 
present invention; 
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Fig. 6 is a block diagram of an example application protocol data unit 
( APDU) suitable for use in accordance with the present invention; 

Fig. 7 is a flow chart for compiling a runtime environment applet, in 
accordance with the teachings of the present invention; 
5 Fig. 8 is a flow chart for building a file system for use on an integrated 

circuit card, in accordance with the teachings of the present invention; 

Fig. 9 is a flow chart illustrating the method steps of executing a runtime 
en\ ironment applet on the innovative ICC of Fig. 5, in accordance with the 
teachings of the present invention; and 
10 Fig. 10 is a block diagram of an example storage medium having stored 

thereon a plurality of executable instructions including instructions which, when 
executed, implement the development agent of the present iiVvention, according to 
an alternate embodiment of the present invention. 

15 nFTAn.ED DESCRIPTION OF THE PR FFERRED EMBODIMENT 

Example Network 

Fig. 2 illustrates an example data network 200 including an integrated circuit 
card 208 incorporating the teachings of the present invention. As shown, network 
200 includes a host system 202 coupled to ICC 208 via communication medium 

20 204 and card reader 206. Host system 202 includes an operating system 210 and 
one or more host applications 212. The innovative ICC 208 is shown comprising a 
runtime environment 214. a file system 216 and a storage medium having stored 
thereon one or more code files and one or more discrete data files (cumulatively 
referenced as 218). The communication medium 108 is intended to represent any of 

25 a number of typical communication links including, but not limited to, a proprietary 
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data bus, an industry standard data bus, a local area network (LAN), a wide area 
network (WAN), or a global area network (e.g., the Internet). 

According to the teachings of the present invention, a runtime environment 
applet is invoked on ICC 208 upon receipt of a command from an application 212 
5 executing on a host system 202 which identifies at least one code file and one data 
file form the discrete code and data files 218. Unlike prior art smart card 
implementations wherein the bytecodes and data necessary to implement a runtime 
environment applet were saved as a single file and implemented by the runtime 
environment, innovative smart card 208 includes an innovative file system 216 
10 which facilitates sharing of discrete code and data files. It will be appreciated, 
based on the description to follow, that the innovative file system facilitates 
modification tc ICC functionaliry without the need to modify the data stored on the 
ICC. 

Card reader 106 provides a necessary interface between ICC 208 and a 
15 computing system such as, e.g., host system 202. Card readers are typically 
designed to support any of a number of standardized communication protocols 
supported within the smart card community and, in this way, can typically 
accommodate smart cards adhering to any of the recognized communication 
standards from any smart card manufacturer. In this regard, card reader 206 is not 
20 chip- or card-specific. For purposes of this discussion, card reader 206 includes the 
necessary hardware and software resources required to support the interlaced debug 
protocol of the presem invention. Consequently, card reader 206 is merely intended 
to be illustrative of card readers typically known within the art. 

For ease of explanation, and not limitation, host system 202 is depicted 
25 within Fig. 2 as comprising a plurality of executable applications 212 and an 
operating system 210, as shown. According to one aspect of the presem invention. 
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to be described more fully below, host system 202 may well include an ICC 
application development agent as one or more of applications 212. The ICC 
development tool includes a compiler to translate a single source code file into a 
discrete code file and a data file for storage on ICC 208. In addition, development 

5 tool includes a file system builder, which takes a description of the code and data 
files to be provided on ICC 208, and generates a binary image of a file system 
which is loaded into the non-volatile memory of ICC 208 to build the file system. It 
is to be appreciated, then, that the innovative development agent described below 
facilitates the innovative features of ICC 208. When endowed with the innovative 

10 development agent, host system 202 may well be utilized in association with 
communication medium 204, card reader 206 and innovative ICC 208 as an 
application development system. Further reference lo an application development 
system throughout this application is intended to reference data network 200. 

15 y.TcamDie C omputer Svstem 

In the discussion herein, the invention is described in the general context of 
computer-executable instructions, such as program modules, being executed by one 
or more conventional computers. Generally, program modules include routines, 
programs, objects, components, data strucmres, etc. that perform particular tasks or 

20 implement particular abstract data types. Moreover, those skilled in the art will 
appreciate that the invention may be practiced with other computer system 
configurations, including hand-held devices, personal digital assistants, 
multiprocessor systems, microprocessor-based or programmable consumer 
electronics, network PCs, minicomputers, mainfirame computers, and the like. In a 

25 distributed computer environment, program modules may be located in both local 
and remote memory storage devices. 
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Fig. 3 shows a general example of a computer system 202 incorporating the 
teachings of one aspect of the present invention, and suitable for use within data 
network 200. It will be evident, from the discussion to follow, that host system 202 
is intended to represent any of a class of general or special purpose computing 
5 platforms which, when endowed with the innovative application development 
agent, transforms data network 200 into an application development system. In this 
regard, the following description of computer system 202 is intended to be merely 
illustrative, as computer systems of greater or lesser capability may well be 
substituted without deviating from the spirit and scope of the present invention. 
10 As shown, host system 202 includes one or more processors or processing 

units 132, a system memory 134, and a bus 136 that couples various system 
components ixnciuding the system memor>' 134 to processors 132. 

The bus 136 represents one or more of any of several types of bus structures, 
including a memory bus or memory controller, a peripheral bus, an accelerated 
15 graphics port, and a processor or local bus using any of a variety of bus 
architectures. The system memory includes read only memory (ROM) 138 and 
random access memory (RAM) 140. A basic input/output system (BIOS) 142, 
containing the basic routines that help to transfer information between elements 
within host system 202, such as during start-up, is stored in ROM 138. Host system 
20 202 further includes a hard disk drive 144 for reading from and writing to a hard 
disk, not shown, a magnetic disk drive 146 for reading from and writing to a 
removable magnetic disk 148, and an optical disk drive 150 for reading from or 
writing to a removable optical disk 152 such as a CD ROM, DVD ROM or other 
such optical media. The hard disk drive 144, magnetic disk drive 146, and optical 
25 disk drive 150 are connected to the bus 136 by a SCSI interface 154 or some other 
suitable bus interface. The drives and their associated computer-readable media 
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provide nonvolatile storage of computer readable instructions, data structures, 
program modules and other data for host system 202. Although the exemplary 
environment described herein employs a hard disk 144, a removable magnetic disk 
148 and a removable optical disk 152, it should be appreciated by those skilled in 
5 the art that other types of computer readable media which can store data that is 
accessible by a computer, such as magnetic cassettes, flash memory cards, digital 
video disks, random access memories (RAMs) read only memories (ROM), and the 
like, may also be used in the exemplary operating enviroiunent. 

A number of program modules may be stored on the hard disk 1 44, magnetic 
10 disk 148, optical disk 152, ROM 138, or RAM 140, including an operating system 
158. one or more application programs 160 including, for example, the innovative 
application development agent 120, other program modules 162, and program data 
164. A user may enter commands and information into host system 202 through 
input devices such as keyboard 166 and pointing device 168. Other input devices 
15 (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, 
or the like. These and other input devices are connected to the processing unit 132 
through an interface 170 that is coupled to bus 136. A monitor 172 or other type of 
display device is also connected to the bus 136 via an interface, such as a video 
adapter 174. In addition to the monitor 172, personal computers often include other 
20 peripheral output devices (not shown) such as speakers and printers. 

As shown, host system 202 operates in a networked environment using 
logical connections to one or more remote computers, such as a remote computer 
176. The remote computer 176 may be another personal computer, a personal 
digital assistant, a server, a router or other network device, a network "thin-client" 
25 PC, a peer device or other common network node, and typically includes many or 
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all of the elements described above relative to host system 202, although only a 
memory storage device 178 has been illustrated in Fig. 3. 

As shown, the logical connections depicted in Fig. 3 include a local area 
network (LAN) 180 and a wide area network (WAN) 182. Such networking 
5 environments are commonplace in offices, enterprise-wide computer networks, 
intranets, and the Internet. In one embodiment, remote computer 176 executes an 
Internet. Web browser program such as the "Internet Explorer" Web browser 
manufactured and distributed by Microsoft Corporation of Redmond, Washington 
to access and utilize online services. 
10 When used in a LAN networking environment, host system 202 is connected 

to the local network 180 through a network interface or adapter 184. When used in 
a WAN networking environment, host system 202 typically includes a modem. 1 86 
or other means for establishing communications over the wide area network 182, 
such as the Internet. The modem 186, which may be internal or external, is 
15 connected to the bus 136 via a serial port interface 156. In a networked 
environment, program modules depicted relative to the personal host system 202, or 
portions thereof, may be stored in the remote memory storage device. It will be 
appreciated that the network connections shown are exemplary and other means of 
establishing a communications link between the computers may be used. 
20 Generally, the data processors of host system 202 are programmed by means 

of instructions stored at different times in the various computer-readable storage 
media of the computer. Programs and operating systems are typically distributed, 
for example, on floppy disks or CD-ROMs. From there, they are installed or loaded 
into the secondary memory of a computer. At execution, they are loaded at least 
25 partially into the computer's primary electronic memory. The invention described 
herein includes these and other various types of computer-readable storage media 
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when such media contain instructions or programs for implementing the innovative 
steps described below in conjunction with a microprocessor or other data processor. 
The invention also includes the computer itself when programmed according to the 
methods and techniques described below. Furthermore, certain sub-components of 
5 the computer may be programmed to perform the functions and steps described 
below. The invention includes such sub-components when they are programmed as 
described. In addition, the invention described herein includes data structures, 
described below, as embodied on various types of memory media. 

For purposes of illustration, programs and other executable program 
10 components such as the operating system are illustrated herein as discrete blocks, 
although it is recognized that such programs and components reside at various times 
in different storage components of the computer, aiid are executed by the data 
processor(s) of the computer. 

Fig. 4 illustrates a block diagram of an example ICC development agent 120, 
15 suitable for use in host system 202. As shown, development agent 120 comprises 
106 comprises control logic 402, one or more development application(s) (or tools) 
404, an ICC command set 406, an ICC compiler 408 and a file system builder 410, 

coupled as depicted. 

Control logic 402 intended to represent any of a broad range of logic known 

20 in the art. In one implementation, control logic 402 a processor, while in alternate 
embodiments control logic is a microcontroller, a programmable logic array, or a 
series of executable instructions which perform logic functions. Control logic 402 
communicates with ICC 208 in any of a plurality of standard communication 
protocols. In alternate embodiments, non-standard protocols may well be used to 

25 communicate between controller 402 and ICC 208 such as, for example, a unique 
development communication protocol. Although not specifically denoted, it is to be 
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appreciated that controller 402 communicates with ICC 208, and any other 
peripheral for that matter, via the communication resources of operating system 210 
of host system 202. Insofar as such resources are well known in the art, they need 
not be described further here. 
5 According to the illustrated example embodiment, development agent 202 is 

depicted as including one or more development application(s) or tools 404. These 
tools may well be any of a number of application development tools commonly 
known in the art. That is, application development agent 120 may well be utilized 
with any of a number of development apphcations such as, for example. Visual 
10 Basic or Visual C/C-h- application development tools available from Microsoft 
Corporation of Redmond, WA. Moreover, such applications 404 need not be 
integrated with development agent 120. Rather, agent 120 may well receive source 
code developed using an external application development tool without deviating 
from the spirit and scope of the present invention. It is to be appreciated that by 
1 5 using common software development tools such as those described above, it is to be 
appreciated that the innovative smart card apphcation development system 200 does 
not require the chip-specific, often proprietary software development application 
and associated compilers, linkers and debuggers that are typical of the prior art ICC 
application development systems. 
20 According to one aspect of the present invention, development agent 120 

includes an innovative ICC applet compiler 408. As shown, the ICC applet 
compiler 408 is comprised of a parser 412 and one or more translator(s) 414. The 
translators 414 take source code developed using, for example, one of development 
apphcations 404, and translates it into a lower-level, executable form, e.g., runtime 
25 environment bytecodes or assembly language instructions. It is common to employ 
two or more translator(s) in a compiler, one as a front-end compiler to receive and 
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translate the source code to an intermediate level language, ^d a back-end 
translator to translate the intermediate level code into an executable form acceptable 
to the processor which will ultimately execute the applet. The use of translator(s) in 
compilers is well-known and, as a result, need not be further described here. 

5 In addition to translator(s) 414, ICC compiler 408 includes a parser 412. As 

used herein, the parser 412 analyzes the received code, in either source code, 
intermediate level, or executable form and separates the executable instructions 
from the data. More specifically, in accordance with the teachings of the present 
invention, parser 412 separates the code from the data and saves each in a separate 

10 and independent file. It is to be appreciated that a runtime environment applet 
created by the innovative ICC applet compiler 408 consists of at least two files, one 
code file and one data file. {Inventors, please modify/supplement as 
appropriate} 

In addition to the innovative compiler 408, development agent 120 includes 
15 a file system builder 410. As shown, file system builder 410 includes binary image 
generator 416. As alluded to above, binary image generator 416 receives a 
description of a file system and generates a binary image of the file system 
description. The file system description is an ordered series of commands that 
describe and build the file system. An example subset of the commands used to 
20 create a file system description are provided below, in Table I. 

Parition_si2e n: Sets the size of the file system partition to n bytes. 

Nuin_FCB n: Sets the number of file control blocks created in file 
25 system to n. 

Num_ACL n: Sets the number of access control lists in the created file 
system to n. 
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Sector_size: sets the sector size of the file system in bytes. This is the 
number of bytes that are added to a file each time it needs more 
space. The larger n is, the more unused space there may be in 
files but the more quickly you can access them and the less 
5 overhead space they require. The smaller n is, the more tightly 

the data in the file fits the allocated space, but there is more 
overhead in managing the file. 

Target [x86/8051/AVR]: Sets the target to accommodate either the 
1 0 "x86", "805 1 " or "AVR" processing environments. 

Create_Partition: creates a partition within the file system and populates 
it with a default file and a default access control level. 

15 FILE nicname ACL Aclfilename: creates a file with the given file name 

whose access control rules are in the file with the given ACL file 
name. 



20 



DELETE filename (or directory): deletes a named file or directory. 

KP^Data {GroupUids} Protocol {ProtocolData} : Put data that describes 
a known principal into the current file which must be a file in 
/s/k {INVENTORS, PLEASE ELABORATE} 

25 ACL_Data ResourceOperationlndex ExpresionType {BooleanExpression} : 

Add the given access control rule to the current file. 

Numeric_Data il i2 i3...i/i 

Numeric_Data_At Position=il i2 i3...i/2: this pair of commands enter 
30 numeric data into the current file. The first version enters the 

data at the current position in the file and the second version sets 
the current position before begirming entry. 

ASCII^Data CharacterString 
35 ASCII_Data_At Position=CharacterString: this pair of commands enter 

ASCII encoded data into current file. The first version enters the 
data at the current position, while the second version sets the 
current position before beginning entry at the current position. 

40 Unicode_Data Characterstring 

Unicode_Data_At Characterstring: this pair of commands enter 
UNICODE encoded alphanumeric data into the current file. The 
first version enters the data at the current position, while the 
second version sets the current position before beginning entry. 
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Set_File_ACL FileName AclFileName: sets the access control level of 
the file by the given filename. 

5 Set_File_Size Filename «: sets the size of the file by the given filename 

to the given value in bytes. 

END: terminates reading of the file system description commands by the 
file system builder and invokes the binary image generator to 
10 output a binary image of the file system. 

Table I: Example FUe System Description Syntax and Definitions 

It should be noted that although reference is made to "filenames" in the above 
syntax, this is for ease of explanation only, as other indicators of a file may well be 
used. Examples of suitable file descriptors include, without limitation, file names, 

1 5 file handles, and the like. 

According to one implementation, the file system description is supplied to 
file system builder 410 by control logic 402, and includes a list of code files and 
data files required to provide an ICC with certain functionahty. In on embodiment, 
ICC development agent 120 provides a graphical user interface (not shown) to a 
20 user with a list of available code and data files, enabling the user to dynamically 
create a file system description in a high-level, graphical representation. Based on 
the description received from the user, control logic 402 accesses ICC file system 
command set 406 which includes, at least, the file system syntax identified in Table 
I to generate the file system description. 
25 In an alternate embodiment, one or more applications 404 provide control 

logic 402 with the file system description based on functionality requirements or the 
input of a developer using a higher-level language. 

Once the file system description is received, file system builder 410 invokes 
the binary image generator 416 to generate a binary image of the received file 
30 system description. According to one implementation, the binary image generated 
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from the received file system description is downloaded to non-volatile memory 
(e.g., EEPROM) of an innovative IC card 208. In an alternate embodiment, the 
binary image is provided to a mass-producer of IC cards, which bums (or masks) 
the image on a read-only memory (ROM) device for the IC card. In either case, file 

5 system builder 410 provides an IC card (208) with the ability to uniquely access 
(add, delete, modify) and execute code files and data files independently to 
implement a flexible array of mntime environment applets. 

As alluded to above, ICC file system command set 406 is a library of 
functional commands which control logic 402 utilizes to create and/or communicate 

10 with the file system 216 of an IC card incorporating the teachings of the present 
invention. More specifically, the ICC file system command set 406 provides 
control logic 402 with the vocabulary' required to create, delete, access and execute 
the discrete code and data files 116 of ICC 208. Although ICC file system 
command set 406 is depicted as a separate functional block, this is for ease of 

15 illustration and explanation. It will be appreciated that ICC file system command 
set 406 may well be integrated with other functional elements such as, for example, 
control logic 402 without deviating from the spirit and scope of the present 
invention. 

According to one implementation, control logic 402 communicates with file 
20 system 216 using the innovative file system command set in accordance with a 
standard communication protocol such as, for example, International Standards 
Organisation (ISO) 7816 T=0, or T=l. 

Although depicted as a separate functional elements, those skilled in the art 
will appreciate that compiler 408 and/or file system builder 410 may well be 
25 integrated within control logic 402. Accordingly, the teachings of the present 
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invention may well be practiced with variation from the exemplary embodiment 
without deviating from the spirit and scope of the present invention. 

Example Integrated Circuit Card 
5 Fig. 5 illustrates a block diagram of an innovative integrated circuit card 208 

incorporating the teachings of the present invention in greater detail. As shown, IC 
card 208 includes the I/O port 102, runtime environment 112, non- volatile and 
volatile mcmor>- (106 and 108) of prior art IC cards. In addition, ICC 208 includes 
control logtc 502. operating system with native functions 504, each modified to 
10 accommodate the innovative ICC file system 216 and a plurality of discrete code 
files and data files 506-5 1 8. 

As used herein, control logic 502 is intended to represent any of a number 
control means known in the art, such as those described in association with conn-ol 
logic 102. However, such control logic is modified, as necessary, to recognize and 
15 implement instructions from the innovative file system command set. In this 
regard, control logic 502 enables a host system to access or execute discrete code 
and data files 506-518 via the operating system 504 and the ICC file system 216. 
Similarly, operating system 504 is modified only to the extent necessary to 
accommodate ICC file system 216 and the discrete code and data files 506-518. An 
20 example of a suitable file system is the Smart Card for Windows operating system 
commonly available from Microsoft Corporation, of Redmond, WA. 

As introduced above, to implement a nmtime applet in ICC 208, control 
logic 502 receives an Execute command fi-om a host denoting a code file and a data 
file. According to one embodiment of the present invention, the received command 
25 is in the form of an application protocol data unit (APDU). An example APDU is 
graphically illustrated with brief reference to Fig. 6. 
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As shown, Fig. 6 graphically illustrates an application protocol data unit 
suitable for use in accordance with the present invention, to communicate file 
system command set instructions between a host system 202 and an innovative ICC 
208, according to one embodiment of the present invention. As shown, APDU 600 

5 is comprised of a mandatory header 602, a conditional body 604, and a mandatory 
trailer 606. The mandatory header includes a class byte 608, instruction byte 610, 
and parameter bytes 612 and 614. The conditional body includes a length field 616, 
which denotes the number of bytes in the data field, and the number of bytes 
expected in any response. The data field 618 includes the data, if any, transmitted 

1 0 jn the APDU. The mandatory trailer field 606 is comprised of status bytes 620 and 
622. respectively. 

, According to the teachings of the present invention, a host system 202 
implements a runtime environment applet within ICC 208 by issuing an EXECUTE 
command of the form: 



15 



Execute (code_filename,data_filename) (I) 



As shown, a runtime environment applet executed in accordance with the teachings 
of the present invention requires both a code filename and a data filename. As 
20 shown in Fig. 6, the present invention provides for different combinations of code 
and data files, thereby enabling a code file to share data files, and for a code file to 
use multiple data files, without the need to integrate the content of the data file into 
a single applet file. 



25 



Example Operation 
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Fig. 7 is a flow chart of an example method for compiling a runtime 
environment applet using a development agent incorporating the teachings of the 
present invention, according to one aspect of the present invention. For ease of 
explanation, and not limitation, the method of Fig. 7 will be developed with 
5 continued reference to Fig. 's 1-6. 

Turning to Fig. 7, the method begins with step 702, wherein the innovative 
ICC applet compiler 408 receives the source code to be compiled. More 
specifically, a development application (e.g., 404) provides control logic 402 of 
development agent 120 with a file containing source code in a high-level 
10 programming language, which must be compiled to an executable form for use in 
an IC card, e.g., ICC 208. 

According to one impleir.entation, ICC applet compiler 408 analyzes the 
received source code to parse data segments from bytecode segments, step 704. As 
described above, parser 412 receives the source code, identifies data objects within 
15 the source code, and separates the data objects from the executable bytecodes. 
Each data object is assigned a relative location in the data file. A reference to this 
relative location is inserted to the code file that is being generated. In the second 
pass of the compiler, it decides on the absolute addresses of each data object and 
generates the data file accordingly. At the same time, it replaces all the data objects 
20 references in the code file with actual addresses. 

In step 706, the bytecode and data objects are passed to the translator(s), as 
they are translated into an executable form. More specifically, the bytecode and 
data objects of the applet are translated into a form suitable for execution by the 
control logic 502 of the IC card 208. In this regard, compiler 408 is chip-specific 
25 although it is anticipated that translator(s) 4 12 for control logic suitable for IC card 
applications may well be provided within compiler 408. 
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Although the illustrated example embodiment invokes the parsing step 704 
before the translation step 706, those skilled in the art will appreciate that there may 
be advantages to reversing this order. That is, it may be more convenient to first 
translate the received source code to some intermediate-level, compiler language. 

5 One common language is the static single assignment (SSA) form, which has the 
inherent property that reoccurring variables (i.e., local variables within a method) 
are uniquely identified within the SSA form. Accordingly, it may prove 
computationally easier to translate the received source code to an intermediate-level 
language, parse the code from the data, and then perform a back-end translation 

10 down to executable form. In another embodiment, it the entire translation step(s) 
may be completed, wherein the code is parsed from the data while in executable 
form. Regardless, all such variations are anticipated within the scope and spirit of 

the present invention. 

In step 708, ICC applet compiler 408 generates two files from the received 
15 source code, one each for the bytecode (i.e., the code file) and for data (i.e., the data 
file). More specifically, once the parsing and translation steps have been 
completed, the executable code is saved in a discrete code file, while the data is 
saved in a discrete data file. In this way, data files may be shared across code files 
providing for more flexible implementations. 
20 Turning now to Fig. 8, the operation of the innovative file system builder 

410 will be described, according to one aspect of the present invention. As shown, 
the method begins with step 802, wherein the file system builder 410 receives a file 
system description. As described above, in accordance with one example 
embodiment, the file system description is generated by control logic 402 based on 
25 received user (developer) input and the ICC file system command set 406 described 
with reference to Table I. 
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The received file system description is read, step 804, and a binary image of 
the file system is created, step 806. As described above, binary image generator 
416 reads the ordered series of commands describing the file system, and generates 
a binary image of the file system to create and implement the file system. 

5 In step 808, the binary image created in step 806 is loaded into the non- 

volatile memory of a suitable integrated circuit card such as, for example, ICC 208. 
According to one embodiment of the present invention, the created binary image 
representation of the file system is loaded into the non- volatile memory 106 of ICC 
208 from control logic 402 of development agent 120. In an altemate embodiment, 

10 the binary image representation of the file system is stored by control logic 402 in 
an accessible storage medium, and is masked (burned) into read-only memory 
( ROM) during the manufacture of ICC 208. 

Fig. 9 is a flow chart illustrating the method steps of executing a runtime 
environment applet on the innovative ICC of Fig. 5, in accordance with the 

1 5 teachings of the present invention. As shown, the method begins in step 902 when 
IC card 208 receives a command to invoke a runtime environment applet. More 
specifically, control logic 502 receives a command in the form EXECUTE 
(code_filename,data_filename) via I/O pon 102, and invokes an instance of runtime 
environment 214 to execute the applet defined by the identified code file and data 

20 file. With reference to Fig. 5, for purposes of illustration, assume that codefilel and 
datafileS are designated. Accordingly, the command EXECUTE 
(codefilel, datafileS) is received by control logic 502. It should be appreciated, 
given the scope of the discussion, that any of a number of altemate means may be 
used to invoke an applet and/or application in accordance with the teachings of the 

25 present invention. In one implementation, for example, the activation of the applets 
(and the selection of the code and data file) can be achieved by an implicit 
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command such as "Execute" or be explicitly selected by an event (true some sort of 
a translation/dispatching table). 

In step 904, controller 402 passes the received file names 
(codefilel.datafileS) to file system 216 to retrieve the files from non-volatile 
5 memory 106. In step 906, the identified code file and data file are retrieved and 
loaded into the runtime environment (RTE) 214, and the identified code file 
(codefilel) is executed until reference to required data is reached, step 908. In step 
910, the RTE accesses the identified data file (datafileS) and performs the desired 
operation in the data file. 
10 In step 912, a determination of whether the end of the applet has been 

reached. If, after performing the operation in the data file, the code file has 
additional executable code, the process continues with step 908 and the bytecode is 
executed until another reference to a data file operation is reached. If, however, in 
step 912 the end of the executable code of the identified code file is reached, the 
1 5 applet ends, and any updates to the identified data file (datafileS) are made. 

Fig. 10 is a block diagram of an example storage medium having stored 
thereon a plurality of executable instructions including instructions which, when 
executed, implement the development agent of the present invention, according to 
an alternate embodiment of the present invention. In general. Fig. 10 illustrates a 
20 storage medium/device 1000 having stored thereon a plurality of instructions 1002 
including at least a subset of which that, when executed, implement the innovative 
features of development agent 120 of the present invention. When executed by a 
processor of a host system, the executable instructions implementing development 
agent 120 perform the compiling and file system building functions described 
25 above. 



. _r/US00/12932 

WO 00/68902 ^ 

24 

As used herein, storage medium 1000 is intended to represent any of a 
number of storage devices and/or storage media known to those skilled in the art 
such as, for example, volatile memory devices, non-volatile memory devices, 
magnetic storage media, optical storage media, and the like. Similarly, the 
5 executable instructions are intended to reflect any of a number of software 
languages known in the art such as, for example, C, C++, Visual Basic, Java, 
Smalltalk, Lisp, extensible Markup Language (XML), and the like. Moreover, it is 
to be appreciated that the storage medium/device 1000 need not be co-located with 
any host system. That is, storage medium/device 1000 may well reside within a 
10 remote server communicatively coupled to and accessible by an executing system. 
Accordingly, the software implementation of Fig. 10 is to be regarded as 
illustrative, as ahemate storage media and softu-arc embodiments are anticipated 
within the spirit and scope of the present invention. 

fsAlthough the invention has been described in language specific to 
15 structural features and/or methodological steps, it is to be understood that the 
invention defined in the appended claims is not necessarily limited to the specific 
features or steps described. Rather, the specific features and steps are disclosed as 
preferred forms of implementing the claimed invention. 
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CLAIMS 

1. An integrated circuit card (ICC) comprising: 

a storage device having stored thereon one or more code files and one or 

5 more data files; and 

control logic to implement an ICC runtime environment to execute an applet 
in response to a command identifying a code file and a data file. 

2. An ICC according to claim 1, further comprising: 

10 a file system, employed by the runtime environment, to access and retrieve 

the identified code file and data file fi-om the storage device for use in 
implementing the applet in the runtime environment. 

3. A storage medium having stored thereon a plurality of executable 
1 5 instructions which, when executed, implement the file system of claim 2. 

4. An ICC according to claim 1, wherein a data file may be invoked with 
multiple code files to implement different runtime environment applets. 

20 5. An ICC according to claim 1 , wherein a code file may be invoked with 

multiple data files to implement different runtime environment applets. 



6. An ICC according to claim 1, wherein the command identifying the 
code file and the data file is received from a host system. 
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7. An ICC application development system including the ICC of claim 1 . 

8. An ICC according to claim 1, wherein a runtime environment applet is 
defined by a code file and a data file. 

9. An ICC according to claim 8, wherein an applet is executed in 
response to an Execute instruction that contains an indication to the code file and 
that data file that needs to be executed and/or to an internal or external event that 
indirectly indicates the code file and data file to be executed. 

10. An integrated circuit card (ICC) comprising: 
an operating system; and 

a file system, responsive to the operating system, to add, delete, modify and 

r 

execute discrete code files and data files. 

11. An integrated circuit card according to claim 10, further comprising: 

a runtime environment, responsive to the operating system, to interface with 
the file system to execute a runtime environment applet. 



wo 00/68902 



p8lnJS00/12932 



5 



27 

12. An integrated circuit card according to claim 1 1 , wherein the runtime 
environment selectively invokes one or more code files and one or more data files 
to implement the runtime environment applet. 

13. An integrated circuit card according to claim 1 1 , wherein the runtime 
environment applet is invoked in response to receiving a command from a host 
identifying one or more code files and one or more data files. 

14. An integrated circuit card according to claim 1 1 , wherein an applet is 
10 executed the code file and the data file are executed in response to a command 

received from a host system via the operating system. 

15. An integrated circuit card according to claim 10, wherein the code 
files and the data files implement one or more runtime environment applets. 



15 



20 



16. An integrated circuit card according to claim 10, wherein the file 
system facilitates modification in integrated circuit functionality without modifying 
data files. 

17, An integrated circuit card according to claim 10, wherein the file 
system facilitates addition and deletion of code files independent of data files. 



18. An integrated circuit card appUcation development system 
comprising a computer system communicatively coupled to the integrated circuit 
25 cardof claim 10. 
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19. An integrated circuit readable storage medium having stored thereon 
a plurality of executable instructions to implement the file system of claim 10. 



20. A method for compiling a runtime environment applet for an 
5 integrated circuit card (ICC), the method comprising: 
receiving source code for the applet; and 



translating the bytecode and data into an executable form. 

22. A method according to claim 20, wherein the steps of segregating and 
translating are reversed. 



23. A method according to claim 20, wherein the steps are implemented 
by an applet compiler of a ICC application development system. 

24. A storage medium having stored thereon a plurality of executable 
20 instructions which, when executed, implement the metiiod step of claim 20. 

25. A method comprising: 

receiving a description of a file system for an integrated circuit card (ICC); 

and 



segregating executable bytecode from data into a separate code file and data 



file. 



10 



21. A method according to claim 20, further comprising the step of: 



15 



25 



generating a binary image of the received file system description. 
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26. A method according to claim 25, further comprising: 
loading the binary image into a non- volatile memory of the ICC. 



27- A method according to claim 26, wherein the binary image is 
5 downloaded to an ICC from a development system according to a standard 
communication protocol. 

28. A method according to claim 26, wherein the binary image is masked 
into a read-only mcmor\' of the ICC during ICC manufacture. 



29. A development system comprising a development agent which 
perfomis a method according to claim 25. 

30. A storage medium having stored thereon a plurality of executable 
15 instructions which, when executed, implement a method according to claim 25. 



31. A method for developing a runtime environment applet for execution 
by an integrated circuit card (ICC), the method comprising: 

receiving a high-level source code representation of the applet; 
20 compiling the received source code into at least a code file and a data file; 



and 



generating a binary image of a file system, including at least the code file 
and the data file for storing on the ICC. 
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32. A method according to claim 31, wherein the step of compiling 

comprises: 

analyzing the received source code; 

parsing executable bytecodes from data objects to store the bytecodes in the 
5 code flic and the data objects in the data file; and 

translating the code file and the data file to lower-level language executable 

by control logic of the ICC. 

33, A method according to claim 31, wherein the step of compiling 
10 comprises: 

translating the received source code to at least an intermediate level 
representation ; 

analyzing the received source code in the at least intermediate level 
representation; 

1 5 parsing executable bytecodes from data objects; 

storing the bytecodes in the code file and the data object in the data file; and 
translating the code file and the data file from the intermediate level 
language to a lower level language executable by control logic of the ICC. 

20 34. A method according to claim 31, wherein generating a binary image 

of a file system comprises: 

generating an ordered series of commands representing a received file 

system description; 

reading the ordered series of commands; and 
25 generating a binary image of the ordered series of commands representing 

the file system. 
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35. A method according to claim 34, wherein generating an ordered 

series of commands comprises: 

receiving the file system description from a development application in a 

5 high-level script form; 

accessing a file system command set; and 

translating the high-level script form of the file system description into an 
ordered series of commands utilizing the file system command set. 

I Q 36. A method according to claim 3 1 , further comprising: 

loading the generated binary image into the ICC. 

37. A method according to claim 36, wherein the step of loading 
comprises: 

15 downloading the binary image to non-volatile memory of the ICC from a 

host system using a standard communication protocol. 

38. A method according to claim 36, wherein the step of loading 
comprises: 

20 masking the binary image into a non-volatile memory during a manufacture 

process of the ICC. 

39. A storage medium having stored thereon a plurality of executable 
instructions which, when executed, implement a method according to claim 31. 
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40. A method for executing a runtime environment applet in an 
integrated circuit card (ICC) comprising the steps of: 

receiving a command at the ICC to execute an identified code file and an 
identified data file; 

5 accessing a file system to retrieve and load the identified code file and data 

file; and 

executing the code file through completion, performing operations in the 
data file called for by the executing code. 

IQ 41. A method according to claim 40, wherein the command is received 

form a host system in response to inserting the ICC into a card reader. 

42. A method according to claim 40, further comprising: 

receiving a second command to execute the identified code file with a 
1 5 different identified data file; and 

accessing the file system to retrieve and load the different identified data 

file; and 

executing the code file through completion, performing operations in the 
different data file called for by the executing code. 

20 

43. A method according to claim 40, further comprising: 

receiving a second command to execute a different identified code file with 

die identified data file; 

accessing and retrieving the different identified code file; and 
25 executing the different identified code file through completion, performing 

operations in the identified data file called for by the executing code. 
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44. A compiler, to receive source code for a runtime environment applet 
in a high-level language from a development tool and to generate an executable 
form of the applet consisting of at least a code file and a data file. 

45. A storage medium having stored thereon a plurality of executable 
instructions which, when executed, implement a compiler according to claim 44. 



10 



a non- 



46. A development system comprising a compiler according to claim 44. 

47. A file system builder to receive an ordered series of commands for a 
file system and to generate a binary image of the file system to store in 
volatile memory of an integrated circuit card. 



15 48. A storage medium having stored thereon a plurality of executable 

instructions which, when executed, implement a file system builder according to 
claim 47. 

49. A development system comprising: 
20 an application development tool;' and 

a compiler, to receive source code for a runtime environment applet in a 
high-level language from the development tool and to generate an executable 
form of the applet consisting of at least a code file and a data file. 
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50. A development system according to claim 49, further comprising: 
a file system builder to receive an ordered series of commands for a file 

system and to generate a binary image of the file system to store in a non-volatile 

memory of an integrated circuit card. 



wo 00/68902 





7US00/12932 



1/8 




wo 00/68902 



/USOO/12932 



4/8 



9 




wo 00/68902 



m 



l/USOO/12932 



5/8 




wo 00/68902 



# 



7US00/12932 



6/8 



57<^, 7 



700 



Start 




Receive source code for 

APPLET 



702 



"71 



Analyze code to parse data 
segments from bytecode 
segments 



704 



TRANSLATE BYTECODE INTO 
APPROPRIATE LOWER LEVEL 
LANGUAGE 



706 



708 



GENERATE TWO FILES, ONE 

EACH FOR BYTECODE 
(CODE FILE) AND FOR DATA 
(DATA FILE) 



( ^END^^ 



sgg 



Start 




RECEIVE A FILE SYSTEM 
DESCRIPTION 



802 



"7f 



<-804 



READ FILE SYSTEM DESCRIPTION 



Generate a binary image of 

THE received FILE SYSTEM 



806 



808 



Load binary image of file 

SYSTEM into NON-VOLATILE 
MEMORY OF ICC 



wo 00/68902 



800/12932 



7/8 



7^- ^ 



900 



Receive an "execute" 
command from host 



902 



"71 



IDENTIFIED CODE AND DATA 
FILES ARE PROVIDED TO FILE 
SYSTEM 



'904 



IDENTIFIED CODE FILE IS 
LOADED INTO RUNTIME 
ENVIRONMENT (RTE) 



906 



IDENTIFIED 

EXECUTED UN 
TO DATA I 


/ 

CODE FILE IS 
TIL REFERENCE 
S REACHED 


\ 


r 


/ 

RTE ACCESSES THE DATA FILE 
AND PERFORMS THE DESIRED 
OPERATION IN THE DATA FILE 



v^908 



910 




wo 00/68902 — _f/US00/12932 



8/8 



'Pi^. to 



\ 

1000 



Storage Medium 



Executable instructions 



1002 



Development 

AGENT 



V 



120 



J 



INTERNATIONA 



SEARCH REPORT 



A. CIJ>SSinCATON OF SUBJECT liAlien 

IPC 7 607F7/10 



[No 



PCT/US 



Irtwnattoiwi Ptent ClaaBiflcation (IPC) o r to both naUonal daaailleallcn and IPC 
SEARCHED 

IPC 7 S07F G06F H04L 



According to 

B, FIELDS SEARCHED . 

Minimum documentation eearched (ctewficaiion eyatem loiia«ea oy c««8mcatK)n eymbote) 



laeardied 



i Bectfonicdatat>aaeconaultedduringthe t^temational aearch (name of data t>a»B and. where pmctoil. aeaich tem» uaed) 

UPI Data, EPO-Internal 



I g DOCUtiEHTS CONSIPEREP TO BE RELEVAIfT 
I Cdtegory* 1 CteHon of document, with Indfcation. wherei 



rials, of the relevant | 



UO 98 09257 A (GEMPLUS) 
5 March 1998 (1998-03-05) 

abstract; claims; figures 

page 2, line 20 -page 7, line 8 

page 10. line 6 -page 23, line 7 

EP 0 466 969 A (SIEMENS NIXDORF 

INFORMATIONSSYSTEME) 

22 January 1992 (1992-01-22) 

abstract; claims; figures 

column 3, line 3 - line 50 

EP 0 190 733 A (TOSHIBA) 
13 August 1986 (1986-08-13) 
the whole document 



j"Y| Further documents are Bated in the oontinualion of IxjxC. 

' Special categoiiee of cited documenta : 

•A* document defining the general state of the art which la not 

^Swktefed to t)e of particular relevance 
■E' eaiiier document but pubfiahed on or after the Wemational 
fiEngdate 

1 • Hoeument which may throw doubts on pciorty claim(8) or 
citation or other special reason (as specified) 

•O- document refemng to an oral dacloeure. use, exhibition or 
other means 

•P' document pubfishedpnof to the Wemational fBIng date but 

later than the priority date claimed 
■ Date of the actual completion of the intemational aearch 

2 October 2000 

I Mama and mailing addreea of the ISA 

European Patent Office, P.B. 5618 Patentlaan 2 
NL - 2280 HV RiiBwnK 
Tel. (431-70) 340-2040. Tx. 31 651 epo nl. 
Fax: (+31-70) 340-3016 



-/- 



Relevant to daim No. 

1-3, 
6-41, 
44-50 



1-6, 

8-17, 

40-43 



1,3,10, 
40 



Patent family membem are lletod In annex. 



T later document PuMW^daft^ilS JSfSlf^^iiSSS^ 
or ortortty date and not in oonfUot with the application but 
cited to understand the principle or theory undertyingthe 
invention 

•X* document of particular relevance: the claimed invof^jp" 
^SwSrt be cS«Bidered novel or cannot be consKlei^^ 
invoh/e an inventive step when the document la talnnalone 

•Y* documentof particular relevance: the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined v«th one or more other such docu- 
ments, such combination being obvious to a person stoned 
inttie art. 

document member of the same patent family 
Date of mailing of the intemational search report 



10/10/2000 
Authorized officer 



David, J 



FoimPCT/ISAaiO{»< 



01) (July 1992) 



page 1 of 2 



INTERNATIO 



SEARCH REPORT 



PCT/US 



"2932 



1 CJConMnu-tlon) DOCUMEKTS CONSIDERED TO BE RELEVAMT 


Relevant to daim No. 1 


1 Category* 1 


CitatkMi of documorit. with incfcatioawhwe approprtate. of the relevant paasageo 





A 
A 
A 
A 
A 

A.P 



6 August 1992 (1992-08-06) 

UO 98 43212 A (VISA INTERNATIONAL SERVICE 
ASSOCIATION) 1 October 1998 (1998-10-01) 

WO 98 19237 A ( SCHLUMBERGER TECHNOLOGIES) 

7 May 1998 (1998-05-07) 

WO 98 52160 A (MONDEX INTERNATIONAL) 
19 November 1998 (1998-11-19) 

EP 0 292 248 A (THE GENERAL ELECTRIC 
COMPANY) 23 November 1988 (1988-11-23) 

EP 0 949 595 A (CITICORP DEVELOPMENT 
CENTER) 13 October 1999 (1999-10-13) 



2 



Fcmi PCT/lSAfflW (ooi«*«»a(10B Of eaoond th-ll 1808) 



Daae 2 of 2 



INTERNATION 

InlenMUenon 



SEARCH REPORT 

lUy mombers 



PCT/US 



No 

32 



PatBiit document 
cHBd in search report 



Publication 
date 



WO 9809257 



05-03-1998 



EP 0466969 A 22-01-1992 



EP 0190733 A 



13-08-1986 



UO 9213322 A 06-08-1992 



WO 9843212 A 01-10-1998 



WO 



9819237 A 07-05-1998 



WO 9852160 A 



19-11-1998 



Patent famay 



US 
AU 
CA 
EP 



5923884 A 
4842897 A 
2233217 A 
0858644 A 



AT 
DE 
US 



100229 T 
59004248 D 
5293577 A 



EP 292248 A 23-11-1988 



JP 
DE 

FR 
DE 
DE 
EP 
ES 
OP 
US 



61177585 A 
3684932 A 



2673476 
69205425 
69205425 
0589884 
2082451 
6504862 
5473690 



A 
D 
T 
A 
T 
T 
A 



AU 
EP 
EP 
US 



6578698 A 
1004992 A 
1021801 A 
6005942 A 



AU 
AU 
EP 



722463 B 
4911897 A 
0932865 A 



AU 

AU 

AU 

AU 

AU 

AU 

AU 

AU 

AU 

EP 

EP 

EP 

EP 

EP 

EP 

EP 

WO 

WO 

WO 

WO 

WO 

WO 

WO 

WO 



6299698 
7776798 
7776898 
7776998 
7777098 
7777198 
7777298 
7777398 
7777498 
0963580 
0981807 
0985202 
0985203 
0976114 
0985204 
0981805 
9837526 
9852158 
9852159 
9852161 
9852152 
9852162 
9852163 
9852153 



A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 



GB 
AU 
JP 
NO 



2204973 A 
1643488 A 
1064033 A 
882140 A 



PubOcalion 
date 



13-07-1999 
19-03-1998 
05-03-1998 
19-08-1998 



15-01-1994 
24-02-1994 

08- 03-1994 

09- 08-1986 
27-05-1992 



04- 09 
16-11- 
21-03- 
06-04- 
16-03- 
02-06- 

05- 12 



1992 
1995 
■1996 
-1994 
■1996 
-1994 
-1995 



20- 10-1998 
31-05-2000 
26-07-2000 

21- 12-1999 



03- 08-2000 
22-05-1998 

04- 08-1999 



09-09- 
08-12- 
08-12- 
08-12- 
08-12- 
08-12- 
08-12 
08-12 
08-12- 
15-12- 

01- 03- 
15-03- 
15-03- 

02- 02- 
15-03- 
01-03- 
27-08- 
19-11- 
19-11- 
19-11 
19-11 
19-11 
19-11 
19-11 



1998 
1998 
-1998 
-1998 
■1998 
-1998 
-1998 
-1998 
-1998 
-1999 
-2000 
-2000 
-2000 
-2000 
•2000 
-2000 
-1998 
-1998 
-1998 
-1998 
-1998 
-1998 
-1998 
-1998 



23- 11-1988 

24- 11-1988 
09-03-1989 
21-11-1988 



FeiRi PCT/ISA«10(p«iiHamlly m»*) IM» 



page 1 of 2 



INTERNATIONA SEARCH REPORT 



>N^ 



PCT/US 



00/tI932 



Patent document 
caed in search report 



Publication 



Patent family 
membe((s) 



PubBcaAon 



EP 292248 



ZA 



8803412 A 



22-02-1989 



EP 0949595 



13-10-1999 



BR 
OP 



9901213 A 
11345266 A 



11-01-2000 
14-12-1999 



Foftn PCT/ISAAIO (pstart famly mex) (July 1802) 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 



□ OTHER: 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 



